Day 1｜開場：為什麼用 JavaScript 做「可長期經營」的記帳 App，而不是又一個 Todo 記帳器

系列：用 JavaScript 打造可長期經營的記帳 App：StrawMoneyBook 實戰
賽組：2026 iThome 鐵人賽 · 主題競賽 · JavaScript 組
產品： StrawMoneyBook · 開發者 Wiki

先講結論

如果記帳 App 只做「新增一筆 → 列表顯示 → 統計本月」，用任何語言都能很快做完。
真正難的是：這份帳本還要在一年、三年後仍然正確、可還原、可升級、可在手機與網頁之間繼續活著。

本系列會以真實產品 StrawMoneyBook 為主線，說明為什麼我會用 JavaScript（Vue 3 + Capacitor + Node.js） 去做這件事，以及「可長期經營」跟「又一個 Todo 記帳器」差在哪裡。

1. Todo 記帳器長什麼樣？

很多入門專案的記帳器，本質上是 Todo List 換皮：

Todo 記帳器追求的是「今天能 demo」。
長期經營追求的是「明天使用者升級 App 後，三年前的帳還在，而且語意沒被偷偷改寫」。

後者才是本系列要寫的戰場。

2. 「可長期經營」到底在經營什麼？

以 StrawMoneyBook 來說，使用者不是只記「今天午餐 120」。真實金流通常會串成流程：

一筆支出
  ├─ 進入預算與分析
  ├─ 可報銷 → 進入報銷狀態 → 導入請款單 → 完成後回寫
  ├─ 借出／借入 → 還款／結清
  └─ 預算剩餘 → 自動或手動進存錢罐（不混入可支配餘額）

再加上：

• 多帳本：個人、家庭、專案、副業要切開
• 訂閱與提醒：週期扣款不是一次性表單
• 同步與備份：Google Drive／WebDAV／共同帳本
• 跨端：瀏覽器可用，Android 也要能離線記

這些需求一出現，App 就不再是「CRUD 列表」，而是一套有不變式（invariants）的作業系統。

所謂不變式，舉幾個本系列後面會反覆出現的例子：

1. 金額不變式：顯示可以是 1,234.56，儲存必須是整數 minor（例如分）。
2. 帳本上下文：幾乎所有功能都以「目前活動帳本」為邊界，不能串錯資料。
3. 升級安全：schema／App 版本變了，不能默默清空本機庫假裝修好。
4. 語意保全：同步或修復時，寧可擋住危險操作，也不要為了「畫面看起來正常」刪交易。

Todo 記帳器通常沒有這些不變式；有的話也只寫在 README，沒寫進程式與測試。

3. 為什麼選 JavaScript？不是為了「什麼都能寫」的口號

坦白說：金流核心邏輯用任何語言都能做。我選 JavaScript，是因為它剛好對上「長期經營」需要的三個現實條件。

3.1 同一套產品心智，要同時服務 Web 與 App

StrawMoneyBook 的前端是 Vue 3 + Vite + Pinia + Vue Router，再用 Capacitor 包成 Android App。

這代表：

• UI 與大部分業務流程可以用同一套 JS／Vue 維護
• 真的碰到裝置能力（通知、檔案、原生 SQLite、銀行 WebView 自動化）才下沉到 plugin／原生層
• 官網測試版與手機 App 不會變成兩個完全無關的產品

對小團隊（甚至個人開發）來說，減少「同一功能寫兩次」，比追求某種語言的理論效能更重要。

3.2 本機資料與後端協作，都能留在 JS 生態

長期記帳一定會碰到兩種資料場景：

• 本機優先：離線可記、啟動要快 → 瀏覽器端 sql.js／sqlite-wasm；Android 端原生 SQLite
• 協作與帳號：共同帳本、邀請、Google 登入 → Node.js + better-sqlite3 後端

前後端都在 JS 生態時，型別約定、錯誤碼、測試腳本、發版流程比較容易收斂成同一套工程文化。
本系列後面會寫：哪些該放 Pinia、哪些該進 Service／Repository、哪些絕對不能只活在元件裡。

3.3 JavaScript 的危險，剛好逼你把「長期」設計出來

JS 對金流開發者不算友善：

• 0.1 + 0.2
• Date 時區與跨月邊界
• 非同步競態（同步還沒結束又切帳本）
• 前端「方便」導致業務規則散落在十個元件

這些不是讓我放棄 JS 的理由，反而是系列要正面處理的題目：
用紀律把動態語言做成可維護系統。

如果你只會用 JS 做 Todo，這個系列會刻意把你往「系統」推一把。

4. StrawMoneyBook 在這個系列中的角色

這不是從零教 Vue 語法的入門課，也不是純產品行銷文。

StrawMoneyBook 在這裡是：

• 真實案例：有實際使用者情境、真實發版與真實踩坑
• 可對照的程式結構：frontend（Vue/Capacitor）+ backend（Node）
• 可驗證的主張：講「禁止 silent wipe」，就要能指出為什麼自動重建空庫是災難

目前技術棧摘要：

你不需要先裝好整套環境也能讀；但每篇都會盡量給「可對應回真實專案決策」的程式碼與架構說明。

5. 30 天你會看到什麼路線？

粗分五個階段：

1. 起手（架構與狀態）
   為什麼帳本是上下文、Pinia／Service 怎麼切、Vite monorepo 怎麼撐開發體驗。

2. 本機資料與不變式
   minor 金額、migration、降版防護、recovery backup、完整性掃描。

3. 金流業務建模
   三種記帳入口、發薪週期預算、借貸、報銷請款、存錢罐、訂閱。

4. 跨端與同步
   Capacitor 邊界、共同帳本 API、Drive／WebDAV、銀行／載具同步的分層。

5. 品質與收斂
   Playwright、版本號策略、更新鏈、以及「治本不治標」的工程文化總結。

每一篇會盡量固定這個寫法：

今日問題 → 設計取捨 → 程式碼／流程 → 踩坑 → 可複用結論

6. 這篇先帶走的三句話

1. Todo 記帳器優化的是輸入速度；長期金流工具優化的是正確性與時間。
2. 選 JavaScript，不是因為它最完美，而是因為它能用同一套語言覆蓋 Web、跨端與 Node 後端，讓小團隊扛得住複雜度。
3. 本系列的主角不是「又做了一個 App」，而是「如何用 JS 把金流不變式寫進架構裡」。

明天開始會進入產品地圖：從「活動帳本」看 StrawMoneyBook 的功能切分，以及前端路由／Store 如何反映這個世界觀。

今日小結

如果你也在用 JS 做「會活很久」的產品，歡迎之後在文章底下留言你最怕的坑：金額、同步、還是升級。
我們下篇見。